Skip to content

Conversation

@citizen-stig
Copy link
Member

@citizen-stig citizen-stig commented Jan 20, 2026

Description

Adds a check for higher nonce in Evm.pending_transactions

  • I have updated CHANGELOG.md with a new entry if my PR makes any breaking changes or fixes a bug. If my PR removes a feature or changes its behavior, I provide help for users on how to migrate to the new behavior.
  • I have carefully reviewed all my Cargo.toml changes before opening the PRs. (Are all new dependencies necessary? Is any module dependency leaked into the full-node (hint: it shouldn't)?)

Testing

All existing tests are passing

Docs

No updates

@citizen-stig citizen-stig changed the base branch from dev to eip-1898-blockid January 20, 2026 16:48
@citizen-stig citizen-stig force-pushed the pending-transaction-handling branch from 31bbfbe to ecaa36b Compare January 20, 2026 16:48
@citizen-stig citizen-stig changed the title Pending transaction handling EVM: Pending transaction handling nonce Jan 20, 2026
Base automatically changed from eip-1898-blockid to dev January 21, 2026 18:36
@citizen-stig citizen-stig force-pushed the pending-transaction-handling branch from ecaa36b to 434ec95 Compare January 22, 2026 07:32
@citizen-stig citizen-stig marked this pull request as ready for review January 22, 2026 09:44
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 22, 2026

Greptile Overview

Greptile Summary

Enhanced eth_getTransactionCount to account for pending transactions when calculating nonces. The implementation now checks pending transactions for the given address and returns the max of the committed nonce and the highest pending nonce + 1.

Key changes:

  • Added get_pending_transaction() method to search pending transactions by hash
  • Modified get_transaction_count() to iterate through pending transactions and find the highest nonce for the address
  • Added from_recovered_pending() helper to format pending transactions without block context
  • Updated get_transaction_by_hash() to fall back to pending transactions if not found in committed state

The logic correctly handles the case where no pending transactions exist (returns 0, then takes max with committed nonce). However, the approach of using only the maximum pending nonce may not handle nonce gaps optimally - if an address has pending transactions with non-sequential nonces, this could suggest higher nonces than necessary.

Confidence Score: 4/5

  • This PR is safe to merge with minor edge case considerations
  • The implementation correctly addresses the core requirement of checking pending transactions for higher nonces. The code is well-structured and the logic is sound for the common case. The confidence score of 4 reflects a minor consideration around nonce gap handling, though this may be acceptable behavior depending on the system's transaction submission patterns.
  • No files require special attention

Important Files Changed

Filename Overview
crates/module-system/module-implementations/sov-evm/src/rpc/handlers.rs Enhanced get_transaction_count to check pending transactions for higher nonces, and get_transaction_by_hash to search pending transactions

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 file reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

Comment on lines +169 to +180
let pending_nonce = if is_pending {
let pending_txs: Vec<_> = self.pending_transactions.collect_infallible(state);
pending_txs
.iter()
.filter(|pending| pending.transaction.signer == address)
.map(|pending| pending.transaction.signed_transaction.nonce())
.max()
.map(|nonce| nonce.saturating_add(1))
.unwrap_or(0)
} else {
0
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential edge case with nonce gaps. If pending transactions have non-sequential nonces (e.g., nonces 5 and 10), this returns 11, but nonce 6-9 would still be valid. Standard Ethereum behavior tracks all pending nonces, not just the max.

Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/module-system/module-implementations/sov-evm/src/rpc/handlers.rs
Line: 169:180

Comment:
Potential edge case with nonce gaps. If pending transactions have non-sequential nonces (e.g., nonces 5 and 10), this returns 11, but nonce 6-9 would still be valid. Standard Ethereum behavior tracks all pending nonces, not just the max.

How can I resolve this? If you propose a fix, please make it concise.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good point!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants